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This research addresses the problems associated with integrating the 
Fundamental Automated Scheduling System (FASS), a PERT/CPM based overhaul 
scheduling device, into U.S. Naval Shipyards. Considered is the problem of how to 
effectivly integrate FASS into all eight shipyards. The mission, organization, duties, 
and constraints of the Naval shipyards are first described then the background 
concerning the requirements for the system is developed. The discussion then shifts to 
the implementation of the system in the shipyards and how each shipyard is utilizing its 
version of FASS. Finally, a summary of recommended actions and suggestions for 
further research is provided. 
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I. INTRODUCTION 



A. PURPOSE 

The current environment of the Naval shipyards is characterized by an ever 
decreasing workload and larger reductions in budgets. This situation calls for ever 
increasing and more uniform management control. The high sensitivity of management 
and schedule control over the overhaul duration and cost has forced the conversion 
from the shipyard MIS based installed PERT/CPM scheduling system to the 
Fundamental Automated Scheduling System (FASS) which can support real time 
network analysis and decision making. This real time scheduling system was aimed at 
allowing the shipyards to better manage manhours and material costs which are critical 
factors associated with cost overruns and the meeting of prescribed overhaul 
completion dates. With cost and time as key variables, the decision was announced on 
11 July 1984 that competitive procurement was underway for Naval shipyards to 
procure an "off-the-shelf' system in lieu of an outside "design and build" contract. 
[Ref. 1] The focus of this research is to examine the Naval Shipyard scheduling system, 
scheduling information flow and organization; then to review the implementation 
strategy used at Puget Sound Naval Shipyard as compared to the strategy for 
implementing the new scheduling system (within the boundaries) of the management 
information system existing at other shipyards. 

B. SCOPE 

This research addresses the problems associated with integrating the 
Fundamental Automated Scheduling System (FASS), a PERT/CPM based overhaul 
scheduling device, into U.S. Naval Shipyards. Due to the uniformity of the shipyards, 
the recommendations and conclusions are applicable to all locations. In this light, all 
activities were consulted in order to benefit from the planning and experience, to date, 
by each activity. Implementation questions were not limited to physical or hardware 
requirements/uses but also covered the areas of management acceptance, utilization of 
existing shipyard systems, graphics utilization, dependability, and worker acceptance 
and understanding. The mission, organization, duties, and constraints of the Naval 
shipyards are first described so that the reader has a better understanding of the overall 
scenario. 
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This section is devoted to the background and profile of the Puget Sound Naval 
Shipyard. The general concept of Automated Scheduling is developed so that the 
reader will have the necessary understanding to relate the use of FASS to solve the 
shipyard scheduling problems. The discussion then shifts to the implementation of the 
system in the shipyards and how each shipyard is utilizing its version of FASS. The 
various versions are analyzed and alternatives are presented, resulting in a summary of 
recommended actions and suggestions for further research. 

C. RESEARCH TECHNIQUE 

Initially, a case study methodology was performed. Information from 
managerial, staff, and production personnel who manage or use FASS resources within 
the operations environment was collected during interviews. Background data on the 
organization of FASS resources at all activities was also gathered. On site data 
gathering and interviews were conducted during one ten day, two three day, and two 
one day visits to Puget Sound Naval Shipyard by LCDR Cole; one two day visit to 
Long Beach Naval Shipyard by LCDR MacDonald; one two day visit to Charleston 
Naval Shipyard and four day attendance of the FASS Users Group conference at 
Portsmouth Naval Shipyard by LCDR Cole. Background reading was conducted to 
better understand the shipyard scenario as well as look at commercial and industrial 
approaches to implementing a computerized scheduling system. The background 
reading consisted of shipyard organization manuals, shipyard MIS manuals, system 
requirements and specifications for FASS and historical information concerning the 
conception of the system procurement. 
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II. PROFILE OF A NAVAL SHIPYARD 



A. GENERAL OVERVIEW 

To help the reader understand the complexity of a Naval Shipyard, especially one 

doing both conventional and Nuclear work, this chapter is devoted to a brief look at 

the general duties, organization, and functions of the shipyard. 

The Naval Shipyard complex consists of eight member yards located in 

Bremerton, WA (Puget Sound), Vallejo, CA (Mare Island), Long Beach, CA, Pearl 

Harbor, HI, Charleston, SC, Norfolk, VA, Philadelphia, PA, and Portsmouth, N’H. 

The official mission assigned to the Naval Shipyard by the Secretary of the Navy is: 

To provide losistics support for .assigned ships and service craft; to perform 
authorized work in. connection with construction, conversion, overhaul, repair, 
alteration, dry-docking, and outfiting of ships and craft, as assigned; to perform 
manufacturing, research, development and test work, as assigned; to provide 
services and "material to other activities and units, as directed bv competent 
authority. [Ref. 2] 

In order to carry out their functions, each shipyard maintains an industrial plant 
with extensive shop facilities: shipfitting, welding, sheetmetal, pipe, inside and outside 
machine, paint, service and tool, electrical and electronics, and rigging. Each shipyard 
also maintains a full range of personnel with engineering, design and shop skills. With 
the exception of nuclear work, shipyards perform basically the same functions; 
therefore, the Puget Sound Naval Shipyard will be used throughout this text as an 
example. 



B. ORGANIZATION 

Pictured in Figure 2.1 is the non-nuclear organization chart for the Production 
Department at Puget Sound. (Ref. 3] The Production Officer has direct access to the 
Shipyard Commander for all areas of production. The Repair Officer reports directly 
to the Production Officer and deals with production priorities and resource utilization. 
In order to discharge these duties the Repair Officer is supported by an Assistant 
Repair Officer, Docking Officer and a Production Control Branch Head. To keep 
track of the status of approximately five to ten ships on a daily basis the Repair Officer 
assigns Ships Superintendents to each ship. 
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Figure 2.1 Partial Production Department 
Non-Nuclear Organization Chart. 
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The Production Control Branch will be examined in detail as this department is 
responsible for the control of FASS. In support of the shipyard Production Officer, 
the Production Control Branch is responsible for: 

* "Providing; workload, workforce, and scheduling data required in the 
management of the Production Department and for inter-department 
information and coordination. 

* Serving as principal assistant to the Repair Officer on matters pertaining to 
workload workforce balance, scheduling, production material control 'and 
master work control systems for all Production Department work. 

* Analvzing current, projected and long range workload and workforce, and 
proposing changes required to achieve balance. 

* Determining phvsical progress of productive work (including support systems 
and preparatory' work)." [Ref. 4] 

To meet the above requirements the Production Control Branch provides; 
PERT CPM schedules to control and sequence the production effort, workload 
forecasts to manage employee resources, and project future manpower requirements. 
The Production Control Branch also provides progress measurement to asses actual 
overhaul status for comparison to the management plan. 

C. OVERHAUL SEQUENCE 

This section provides the reader with a background to understand a typical 
shipyard overhaul sequence. The easiest way to understand this process is to use the 
concept of event management. The event management system is based on establishing 
and monitoring events. An event is defined as a specific accomplishment at a specific 
point in time. The scheduling hierarchy contains five interrelated levels, each level 
more definitive and supportive of the upper tier schedules. The event hierarchy 
contains three levels of events with appropriate management responsibility and 
visibility at each level. The total event level schedule is the third level of the scheduling 
hierarchy. Each key event provides a discrete, well defined point in time where the 
status of related jobs may be examined and the progress evaluated. Shipyard 
Commanders or higher authority determines the key events which will determine the 
actual status of a ship's overhaul. A typical overhaul sequence with key events listed is 
provided in Figure 2.2. The same key events depicted on Figure 2.2 normally establish 
the critical path for the overhaul. 

Although the Key Events shown make the overhaul appear straightforward with 
only a limited number of key events, the reader must be exposed to the complexity of 



13 



dock 



UNDOCK 

STEAMING 

DOCK TRIALS 

SEA TRIALS 



Figure 2.2 Typical Non-Nuclear Overhaul Sequence. 

completing the work leading to a key event. Figure 2.3 displays the typical interrelated 
systems work phases leading to a Key Event. As an example, the Engineering Plant 
Light OfT Key Event represents approximatlv five hundred job orders. The engineering 
plant of a destroyer class ship has four main engine spaces and up to 30 smaller 
auxiliary spaces. Each main engineering space has 15 major systems which contain 
approximately 900 valves and components. Each valve will not only require 
maintenance and or rework during the yard period but will also require inspection and 
testing prior to and during light-off. Now, add the training required by a new crew to 
operate a complex engineering plant with electronic systems, multiply this by four, then 
add the auxiliaries equivalent and the successful occurrence of a key event becomes a 
mind boggling evolution of enormous size that defies the best of management 
techniques and systems. [Ref. 5] 
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Figure 2.3 



Tvpical Interrelated Work Phases 
Leaaing to a Key Event. 
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D. THE OVERHAUL ASSIGNMENT PROCESS 



Normally, a Naval Shipyard does not "bid" for an overhaul contract in the same 
manner as a private shipyard does. Naval Sea System Commands (NAVSEA) and the 
Chief of Naval Operations assign workloads to individual shipyards. Such variables as 
construction, conversion and overhaul schedules, yard capabilities, yard specialties, 
existing homeport policies, and total shipwork all play a role in determining where each 
overhaul is assigned. The individual shipyards provide inputs but do not control the 
assignment process. This process constitutes a factor that can greatly affect a 
shipyard's planning process. Competitive policies and procedures are currently being 
developed which will force Naval Shipyards to "bid" against private shipyards or 
themselves for a portion or all of their assigned work. 

E. SHIPYARD MANAGEMENT CONSTRAINTS 

The constraints placed upon shipyard management are not greatly different from 
those placed on industry, however, they should be briefly reviewed. The four major 
constraints are: available manpower, authorized work, schedule adherence, and 
maximum allowable cost. All four constraints are interrelated. With regard to 
available manpower, the shipyard must employ sufficient labor skills to complete the 
assigned work. To accomplish this, forecasted workloads are derived and a suitable 
workforce is established. Unique from the public sector shipyard is the fact that all 
workers are government employees which removes the option of acquiring manpower 
on a daily basis from a union labor pool. This constraint is often costly when shipyard 
workload varies significantly. 

Estimated cost impacts directly upon both the authorized work, (the second 
constraint) and maximum cost, (the fourth constraint). The estimated cost of work is 
produced by examining current labor and material costs. Given a maximum allowable 
cost of an overhaul, the ship's captain, type commander, and the shipyard develop a 
priority work package of required work that fits within that maximum allowable cost. 

Schedule adherence (the third constraint), is mandated from the Chief of Naval 
Operations level (CNO). The CNO's office controls total force requirements and 
therefore limits the period of time that a vessel can be taken "off the line." 

The four constraints have been described briefly to give the reader an overview of 
a few of the factors that dominate shipyard management. These elements combine to 
severely tax the efforts of the Production and Repair Departments to develop and 
maintain a ship's overhaul schedule. 
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F. SCHEDULE ADHERENCE 

The bottom line of any repair activity is their ability to accomplish proper repairs 
within a limited time frame and budget. More specifically, the shipyard Repair 
Officer's problem is: "When several vessels are in overhaul, how can a master schedule 
be maintained while taking into consideration individual unit schedules, fixed overhaul 
workload, manpower, and cost constraints?" Other factors (i.e., political and 
operational pressures) often occur thereby increaseing the outside contracting 
requirements causing a reduction in the budget and time allotted for the overhaul. 
This situation requires the shipyard management to frequently answer many "What-lf' 
questions in the planning and scheduling of their resources. The problem is very 
complex and no specific algorithm can be used for a solution. 



17 



III. AUTOMATED SCHEDULING BACKGROUND 



A. INTRODUCTION TO AUTOMATED SCHEDULING 

Automated scheduling is intended to be used to manage individual projects in 
conjunction with aggregate planning techniques for inter-project analysis. It is a 
powerful tool for scheduling project activities and for allocating scarce resources 
among project activities. It can also do risk analysis of project budgets and due dates. 
However, in the management of a project-oriented production system, such as the 
Naval Shipyards, major decisions must be made involving aggregate level planning 
issues. These decisions include the planned allocations of available resource time 
among projects and establishment of major milestone target dates for each project. 
Due to the extensive number of automated scheduling packages in use, only one such 
package will be covered here. 

Automated scheduling requires as input data the allocations of resources to a 
project and its target milestone dates. Resource allocations to a project are treated as 
inviolable capacities for the project on the grounds that exceeding such allocations 
would affect other projects. The scheduling algorithms used in an automated 
scheduling package derive schedules meeting the target milestone dates (if feasible) 
without exceeding the allocated resource levels. 

An automated scheduling package may be used to perform two different types of 
analysis which are termed "deterministic" and "probabilistic". [Ref. 6] In deterministic 
analysis a project schedule is derived assuming the work requirements for the activities 
of the project are known. In addition to the optimal schedule, resource load profiles 
corresponding to this schedule are provided as output. In probabilistic analysis, 
scheduling of the project is simulated many times with activity work requirements 
randomized according to probability distributions. The user must specify distributions 
defining probabilities of unplanned rework activities. Also, the software will 
incorporate uniform distributions which randomize the work content of the schedule 
over a set range (80-120%) of given estimates. Shipyards may evolve to probabilistic 
analysis when expertise is developed in the utilization of deterministic analysis. 

Automated scheduling may provide confidence curves for the realization date of 
each milestone and confidence curves for the total hours required of each resource. 
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Resource load profiles reflecting a user-specified confidence level may also be obtained. 
Reviewing the results of such work, the user can assess the risks that trial project 
milestones and resource budgets cannot be met. 



B. SYSTEM DESCRIPTION 

Simulated scheduling is a comprehensive software package for project scheduling 
and analysis developed at the Operations Research Center of the University of 
California at Berkelv. [Ref. 6] It is designed for use in project-oriented production 
systems which have inflexible resource capacities limiting the execution of multiple 
projects with uncertain work requirements. Both tabular and graphical output for 
project scheduled and risk analysis may be provided. This software is the result of 
research concerning the development of mathematical models and techniques for 
production management sponsored by the Office of Naval Research and the Puget 
Sound Naval Shipyard. 

The simulation scheduling package utilizes the VM/SP operating system to 
compile CMS Fortran interactive commands and batch processing code. With some 
appropriate modifications, the Fortran code could be adapted to run on other systems. 

1. Summary of Data Requirements 

The data requirements for simulation scheduling are summarized below. Some 
of the data items are novel compared to other project scheduling software. For this 
reason, a brief discussion of the mathematical models of production will be provided 
following the summary of data requirements. 

* "CPM ACTIVITY NETWORK -- An activitv-on-arc network of all planned 
activities is specified. The "normal" duration lor each activity is specified. 

* RESOURCE HOURS — For each activity, estimated total hours of each 
resource to be applied are specified. These resources are identified bv "shop" 
number. Subcategories are designated bv "work center" number. Activities 
whose resource utilization levels "are not adjustable are designated with a flag 
in the "activity-type" field. 

* TARGET PROJECT COMPLETION DATE - The target due date for 
completion of all activities in the project. 

* TARGET MILESTONE DATES — Target due dates for any other events 
may be specified. If feasible, schedules will be developed meeting the target 
dates. Activities following such events will not be scheduled to 'start earlier 
than the target date, unless all predecessors are complete and it is necessary to 
do so in order to meet other due dates. 

* SHOP CAPACITIES -- Time varving levels are specified for each resource 
allocated to the project. The user must specify the hours/day of each shop 
available to the project and an effective date such levels apply. ' Multiple levels 
and multiple effective dates are allowed. 

* FLOW TRANSFERS — Dependent activities which overlap instead of being 
separated bv strict precedence have a flow transfer percentage specified to 
define the lag in the progress of the two activities. 
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* REWORK SUBNETWORKS -- For probabilistic analysis, subnetworks 
describing potential rework are defined. Each rew r ork subnetwork consists of 
alternative paths of rework activities which mav be required following a 
particular activity in the CPM network. 

* CALENDAR DATA — The starting dates of the individual projects to be 
scheduled/simulated and a list of non-working days is provided. 

* REPORTING DATES — A list of dates for reporting shop and work center 
loading statistics is provided. 

* MISCELLANEOUS PARAMETERS -- To initiate the program, various 
parameters must be specified. These include the number of simulations to be 
performed, the number of work days simulated, upper and lower bounds for 
activity intensify, and the intensity assignment policy." [Ref. 6] 

2. Mathematical Models of Production 

Simulation scheduling utilizes the network logic of the critical path method 
(CPM). In order for the scheduling model to more realistically simulate work in the 
project-oriented production system, such as a naval shipyard, some of the restrictive 
assumptions of CPM had to be relaxed. For example, the duration of many activities 
must be adjustable according to the amount of resources applied to the activity. In 
simulation scheduling, the duration for each activity is determined according to the 
simulated application of resources to the activity. Efficient activity durations and 
schedules are determined by the efficient allocation of project resources among the 
activities of the project. 

3. Resource Utilization 

In simulation scheduling it is assumed that all scarce resources utilized by an 
activity are applied proportionally. Using this assumption, the fraction of the total 
requirement for a resource that is applied to an activity on a particular day is the same 
for all resources utilized by the activity on that day. This fraction is called the 
"intensity of the activity" on that particular day. 

In CP VI, it is assumed that activity intensity is constant from the start to the 
finish of the project. The value of this constant is the reciprocal of the prespecified 
activity duration. However, in simulation scheduling, activity intensity is allowed to 
vary between upper and lower limits defined by the user. The user defines a normal 
duration for each activity which corresponds to a normal intensity. The user also 
defines upper and low r er bounds on activity intensity, expressed as a percentage of the 
normal intensity. The user may also identify fixed intensity activities. Fixed intensity 
activities are ones whose intensity must be held constant at the level corresponding to 
normal duration. All other activities are assumed to have intensities which are 
adjustable between the upper and lower percentage limits. 
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In simulation scheduling, the user must select one of two alternative intensity 
assignment policies known as "upgrading only" and "upgrading and downgrading." In 
the "upgrading only" policy, resources cannot be withdrawn from an activity in 
progress. On the other hand, this is permitted under the "upgrading and downgrading" 
policy. In general, more efficient resource utilization and shorter project durations are 
feasible when activities can be downgraded as well as upgraded. 

4. Activity Dependencies 

In CPM, work flow is represented with strict precedence relationships between 
activities. In simulation scheduling a more general work flow relationship may be 
defined (known as a flow transfer) which may possibly reduce network size. An 
example of this relationship is: Suppose three valves are to be fabricated and then 
installed. As fabrication of each valve is completed the valve may be installed. CPM 
cannot accurately have one activity represent this situation. To be completely accurate 
CPM would have to use three separate valve fabrication activities and three separate 
valve installation activities. 

Using simulation scheduling it is possible to define one activity representing 
the fabrication of three valves and one activity representing the installation of three 
valves with a 33.3% flow transfer specified between them. The 33.3% flow transfer 
insures that the fabrication activity is always 33.3% ahead of the installation activity. 
For example: Installation cannot start until fabrication is at least 33.3% done and 
installation cannot be 66.6% done unless fabrication is 100.0% done. In this way, the 
application of resources to install each valve will not be simulated until after the 
application of resources to fabricate the valve has been simulated even though only 
two activities are used. A 100.0% flow transfer value corresponds to the familiar strict 
precedence of activities. In simulation scheduling the default is 100% flow transfer. 

5 . Probabilistic Networks 

In CPM a given network of activities is represented. In probabilistic analysis, 
using simulated scheduling, an overall network is represented which consists of the 
given network appended with randomly generated rework networks. Many different 
overall networks are scheduled in the course of probabilistic analysis. The user of 
simulation scheduling must provide input data defining the probabilities and structure 
of the rework subnetworks briefly described as follows. 

For each rework subnetwork the user identifies the activity of the given 
network which immediatly precedes the potential rework. For purposes of discussion 
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this activity will be refered to as the "test activity." The rework subnetwork following 
the test activity is defined in terms of alternative paths of rework activities. Each path 
is termed a "branch." The user defines the probability that each branch will arise 
following the test activity. The branch probability may sum to less than 1.0 to 
represent the case in which there is a chance that no rework is required. 

A graph of an example rework subnetwork is presented in Figure 3.1. There 
are three rework branches following the test activity with probabilities 0.35, 0.20 and 
0.05 respectively. For each rework activity on each branch the user specifies a normal 
resource mix (e.g., normal crew requirement). The user also specifies a probability 
distribution for the duration of the rew r ork activity that would be realized if the normal 
resource mix were applied. This distribution is expressed in discrete form. For 
example: The duration distribution for rework activity might be one day with 
probability 0.25 and two days with probability 0.75. Up to five alternative durations 
for each rework activity may be specified. 



TEST ACTIVITY Ilf 
T1IE GIVEN 
NETWORK! 




Figure 3.1 Example of Rework Subnetwork. 
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IV. FASS BACKGROUND 



A. WHY FASS 

The governing body of Naval Shipyards is the Naval Sea Systems Command 
(NAVSEA). In order to supervise and standardize management practices within the 
shipyards. NAVSEA issued NAVSEAINST 4850.9 on February 28 1984. [Ref. 7] The 
design of this instruction was to establish a minimum level of operational procedures in 
the scheduling of non-nuclear shipyard work. The instruction requires each shipyard to 
develop and maintain a hierarchy of five integrated schedules. The descending levels of 
scheduling would consist of more detail which must be upward compatible and 
supportive of all levels above it. The five levels of schedules must also be dynamic and 
updateable to reflect daily schedules up through the Key Event schedule. In addition 
to the scheduling requirements NAVSEA work load forecasting procedures specifies 
data requirements to assist in the shipyard management effort. A sample of these are: 



* "Develop and maintain work performance statistics by hull type (and class if 
appropriate) and availability type by direct labor shop." 

* Base all direct labor workload projections on data provided by the Planning 
Department. Where a "should cost analysis report" nas been prepared, modify 
to will cost" by using an approved performance factor. 

* During the availability, monitor actual performance and recommend revisions 
to the'" PEC as necessary in order that the "will cost" estimate represents the 
shipyard's best estimate 'of final expended direct labor mandays. 

* Prepare and maintain workload forecasts for all major direct labor shops 
including support shops. 

* Prepare quarterly staffing recommendations for all major direct labor shops, 
including support shops, for use by the Management Engineering Office and 
other departments in establishing departmental ceiling and staffing plans. 

* Produce Workload and Resource Reports and associated reports." [Ref. 8] 

Although the above requirements were made to improve shipyard performance 

the existing Automated Data Processing technology at the various shipyards could not 
support the requirements. Shipyard workloads are managed by the Production Control 
Branch using both automated and manual techniques including hand drawn 
PERT/CPM charts and batch inputs to the shipyard management information system. 
Numerous shipyards had already begun utilizing commercial software packages to 
assist in network scheduling; however, most were still incapable of fulfilling the 
NAVSEA requirements even with these packages. 
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The shipyard MIS in the batch mode (for example) returns schedule information 
in one to three days. Manual network drawing may take from two to several weeks. 
With these time constraints the information provided to management was too late and 
of very little use. 

At this point in time the Production Control Branch heads of the shipyards 
collectively examined their inability to meet the NAVSEA requirements and jointly 
developed a solution to the problem. It was determined that the best alternative was 
to obtain a current commercial "state-of-the-art, off-the-shelf', on-line, user-friendly 
software package. Questionnaires were distributed to all shipyards and appropriate 
studies were performed to assess the actual requirements. The results of the 
questionnaires and the studies were transformed into a set of system specifications that 
described the objectives and potential benefits of FASS as follows: 

1. Objectives 

* "To shorten ship availability durations by providing the capability to quickly 
asses remaining work and define appropriate management action.' 

* To increase the productivity of the Scheduling Section by elimination of 
manually prepared CP.VI networks and bar charts. 

* To have access to an automated, interactive project management system 
which can serve as a tool in evaluating the impact of proposed scheduling 
and workload forecast changes and their impact on one another. 

* To have the capability to automatically "forecast resource problems" within 
a given schedule and - identify the CP”M activities involved which warrant 
immediate attention. 

* To have the abilitv to input schedule adherence and progress data from 
remote locations. 

* To establish a more meaningful relationship among project schedules, shop 
manpower resources, workload forecast, and progress data to aid in the 
analysis of performance and monitoring of schedule~adherence. 

* To maintain a "Historical File" for future availabilities." 

2. Potential Benefits 

* "To reduce overhaul durations and increase shipyard productivity. 

* To improve the quality of shipyard schedules. 

* To provide an automated interactive project management svstem which 
would serve as a tool in evaluating the impact of proposed scheduling and 
workload forecast changes and their impact on one another. This on-line 
modeling capacity would allow shipyard management to select the best 
option in a timely' manner. 

* To provide an automatic forecast of resource problems within a given 
schedule and identification of the activities warranting immediate attention. 
This would allow shop managers to review manning problems far enough in 
advance to properly react resolve manloading situations. 

* An automated scheduling svstem would provide the ability to input schedule 
adherence and progress data from remote locations. 
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* To provide a more meaningful relationship among schedule, workload 
forecast, and progress data would allow the analysis of cost and schedule 
performance. 

* To provide for the existence of an automated historical file which would 
reduce scheduling effort bv allowing similar work package schedules to be re- 
used with appropriate changes. This would also promote the sharing of 
work package schedules among shipyards reinforcing overhaul 
standardization and applving lessons learned throughout the shipvard 
community." [Ref. 9] 

B. SYSTEM DESCRIPTION 

The ARTEMIS software procured for the shipyards was a user friendly, on-line, 
strictly deterministic, real time management system package. ARTEMIS has a 
probabilistic analysis network software package which is limited in application and 
therefore has not been procured by any shipyard. The ARTEMIS system utilizes a 
Hewlett Packard Mini 6000 series computer with various printers, plotters, and 
graphics terminals. General characteristics of the overall system include a common, 
high level command language utilized throughout the system. This allow's the first time 
user to be led through the various cycles and allows an advanced user to bypass the 
initial instructions and proceed at their own pace. Self instruction facilities are 
maintained to help new personnel using the system. The established user may develop 
new data entry or retrieval formats and access data within the numerous data sets 
without affecting other users. The system is also capable of on line and/or background 
processing. This capability allows the user to view the indicated process function and 
make corrections or changes as they are displayed. 

A relational database is utilized with the ability of linking up to fifteen data sets 
using dynamically defined key fields. The ARTEMIS system can handle 32.000 
activities per project, 64 calenders, 32 data sets and 256 resources per activity. Data 
input can be accomplished by using a database, manual input, or tape transfer. 

The approximate times involved in obtaining an output from the system can be 
illustrated by viewing tw'o cases. The initial case assumes a busy system with a detailed 
PERT CPM system of several thousand activities such as that required for the 
scheduling of a Destroyer class availability. The time required to receive an output 
from FASS would be approximate one and one half hours, that is time to retrieve 
data from the database, analyze it, and have it ready to plot. This output allows the 
user to see the entire detailed PERT/CPM overhaul schedule. A better example of the 
time savings of this system is shown by looking at a lower level of detail; that is say. 
the four hundred activity level of the previously discussed Destroyer class availability. 
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The time in this case is in the vicinity of twelve minutes; approximatlv two minutes to 
retrieve the data from the database and approximatlv ten minutes to analyze the data 
with the results displayed on a graphics terminal or plotted on any of the various 
plotters available. 

The second case is an example of the day-to-day use of the system. A supervisor 
utilizing the system at a busy time can change information concerning five specific jobs 
involved in the four hundred activities. The five job changes would require about five 
minutes; two minutes for the data retrieval, one minute for the data entry process and 
approximatlv two more minutes for the analysis. In this instance FASS is providing 
the much needed assistance to the supervisors in developing alternative solutions 
through schedule simulation thus illustrating the quick response time that FASS will 
provide to the waterfront supervisors. 

The only limitation to handling multiple projects is the system storage capacity. 
The actual software and hardware makeup of each shipyard's system is individually 
flexible to meet their present needs and support that shipyard's demands. 

C. INITIAL FASS UTILIZATION 

While the initial requirement for FASS was to enable the shipyards to comply 
with the NAVSEA directives on scheduling shipyard management quickly understood 
the magnitude of potential applications available with the system. The ARTEMIS 
package provided a desktop version for project offices and foreman as well as the 
shipyard schedulers and could link a limited number of its terminals to the mini system. 
With this link capability (the combination of remote terminals and the desk top 
program) the problem of real time waterfront information interfacing was addressed. 
The system also provided the shipyard with the ability to reassign job priorities, order 
of start, stop dates, and reconstruction of the networks to determine the affects of these 
changes on the critical path, resources, and other events. The "What-lf capability is 
an immense improvement over the existing techniques used prior to FASS. The 
resulting savings of the several days of manual labor required to develop a new 
PERT CPM schedule after any major changes were proposed during the overhaul 
process was a quantum and very welcome jump in processing rates. 
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V. FASS IMPLEMENTATION CONSIDERATIONS 



A. FASS/MIS INTERFACE 

Implementation of a new subsystem into an existing mainframe computer and 
management information system is a complex and thought provoking exercise in 
looking at both a near term goal (i.e., implementation of a new scheduling application) 
and the long term goal of complete and compatible integration. All eight Navy 
shipyards have acquired the FASS system for scheduling overhaul work on Naval 
ships. This system is a must for management in an era of reduced budgets and 
decreased workloads. The networking analysis and "What-If' features of FASS are 
critical to sound management. The network and management graphics provided by the 
system are necessary to maintain state of the art information presentation to shipyard 
managers. 

A prime implementation consideration is the ability to interface between the 
ARTEMIS 60000 minicomputer (which runs FASS) and the shipyard mainframe 
(Honeywell 6060). This arrangement puts the heavy burden of "number crunching" on 
the mainframe which has the capacity to handle such a memory sink allowing the 
FASS and ARTEMIS 6000 software to assimilate and produce the charts, scheduling, 
and cost readout that schedulers, foreman and managers must have to judge work and 
time critically. The main strategies involved in implementation of the FASS System 
involve: (1) utilization of the mainframe data base for FASS analysis (2) providing 
FASS resultant schedule data to the shipyard mainframe. 

Philadelphia Naval Shipyard advanced the idea of interfacing a minicomputer 
with the shipyard mainframe. Major areas that required thorough coordination were 
as follows: 

* Current mainframe capabilities. 

* Long term capabilities and capacities of the mainframe. 

* Effect of mini/micro computers on the data processing organization. 

* Computer networking. 

The minicomputer approach adopted by Philadelphia was designated PASS 
(Production Automated Support System). A line drawing of this arrangement is shown 
in Figure 5.1. The advantages of such an arrangement are as follows: 
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* Data sharing ability between the mini computer and the mainframe. 

* Ability to share hardware and software throughout the data processing 
department and the shipyard. 

* The capability of combining data files and standardizing formats. 

* Fund usage optimization calling for less equipment and fewer communication 
lines. 




Figure 5.1 Philadelphia FASS Utilization Network,. 

The FASS constraints of data entry, accessibility, and memory capacity are 
eliminated by this PASS. Additionally, this PASS allows the existing terminals in the 
shipyard to obtain data from FASS. This system has been fully implemented at 
Philadelphia and the following benefits are already becoming realized: 



* Schedule quality is improving. 

* The automated interactive project management system has given the shipyard 
the on-line modeling capabilitv for shipvard management to review several 
alternatives of schedule changes and to select the best alternative. 

* Automatic forecasting of resources will allow managers to review manning 
problems far enough in advance to properly resolve those manloading 
problems. 
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The Long Beach Shipyard approach, as shown in Figure 5.2, is for connection of 
the ARTEMIS 6000 minicomputer system with the Honeywell mainframe via modem 
for data flow. This allows FASS to relay as well as retrieve information to the 
shipyard MIS in real-time fashion rather than the previous batch process that took up 
to three days to return the appropriate readout. The FASS software allows the 
mainframe to do the heavy "number crunching" and retrieves and puts that information 
into usable graphics for foreman, schedulers, and managers. 




Figure 5.2 Long Beach FASS Utilization Network. 

A constraint that originally developed at Long Beach has been resolved by the 
data processing department. In order for FASS to be completely interactive with real- 
time information there must be a dedicated port into the mainframe. This constraint is 
based on the Long Beach belief that FASS should function as a front end processor for 
the production scheduling (PS) application of SYMIS. Long Beach has resolved this 
problem by having such a port assigned to the production and planning department 
which has the primary equipment and usage for FASS. A typical "Plan of Actions and 
Milestones" for interfacing FASS to MIS is shown in Figure 5.3. In addition to the 
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advantages cited for Philadelphia Naval Shipyard. Long Beach Shipyard is able to 
realize these potential benefits: 

* A more direct, real-time relationship among workload forecasting, scheduling 
and progress data allows the analysis of cosf and schedule performance. 

* Reduction of overhaul durations and increased shipyard productivity. 

Long Beach Shipyard is in the final stages of full implementation of its FASS 
system. Minor communication protocol and compatibility bugs are being corrected for 
the modem to be the final link between FASS and the mainframe. 

Puget Sound Naval Shipyard developed a networking approach by designing a 
Production Control Database that would be the interface between the SYMIS and 
FASS, replacing the SYMIS PS application. This system network is shown in Figure 
5.4. The obvious advantage to this arrangement is the fact that FASS is freed from 
storage and interface constraints. This type of setup allows the mainframe to continue 
processing shipyard weekly reporting requirements while allowing FASS to create with 
its graphics package more limited and specialized distribution reports. With the proper 
identity codes, schedulers and leadmen can update the database from any number of 
terminals that the shipyard has. This distributed system is a tremendous asset in 
keeping the real-time aspect of data viable for FASS. A new wrinkle with the 
mainframe database and the ARTEMIS 6000 minicomputer is that progressmen and 
schedulers can now conduct "What- If studies on critical path jobs in order to see 
trends and to optimize job scheduling for a more efficient use of manhours. A 
summary of the advantages of the Puget Sound Shipyard concept follows: 

* A real-time, on-line updating capability. 

* Anv increase in the number of shipyard terminals allow more personnel to 
utilize FASS update results. 

* Real time work status is available for "What-If' analysis. 

* The database programs are able to be utilized bv other Naval shipyards due to 
the commonalty of mainframe systems. 

* Anv new' mainframe purchase will not affect use of the Production Control 
database and FASS. 

The FASS/MIS interface at the shipyards may be off-line via magnetic tape or 
on-line via direct communication with the mainframe. The on-line method is used 
daily for progress and schedule updates. The off-line magnetic tape interface is for 
historical or large bulk data transfer between the mainframe and FASS. An important 
interface is between ARTEMIS and the Production Control application. This interface 
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LONG BEACH NAVAL SHIPYARD 
CODE 379 PLAN OF ACTION AND MILESTONES 




Figure 5.3 FASS/MIS Interface Plan of Action and Milestones. 
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MAINFRAME 






Figure 5.4 Puget Sound FASS Utilization Network. 

is extremely important for the overhaul quality between SYMIS outputs and the 
Production Control processes. The on-line method causes the ARTEMIS terminal to 
act as a remote job entry station. 

On the technical level implementation is all but complete at all of the Navy- 
shipyards. The FASS User's Group (will be covered later) w-hich is comprised of the 
personnel directly working with the system in the Production Control branch are 
constantly exchanging information that assists the others in problems that are common 
to all. The current ARTEMIS software release (Rel 6.6.1) is different enough from the 
6.6.0 release (which is the application) that has been implemented that these data 
analysts share their knowledge for the good of all. 

B. ORGANIZATIONAL CONSIDERATIONS 

FASS is proving to be an extremely powerful tool for scheduling, graphics, job 
networking, and cost variance analysis. There is a need for this facet of shipyard 
production control to have a separate code in the nuclear and non-nuclear organization 
of the Navy shipyards. The approved line drawing of the current production control 



branch of shipyard organization is shown in Figure 5.5. A figure reflecting the 
projected organization required to support production control branch ADP functions is 
shown in Figure 5.6. 
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Figure 5.5 Typical Production Control Branch. 
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Figure 5.6 Projected Production Control Branch. 



The reasoning behind such a structure is that the sections of production control 
have the most need for the output of PASS. The above sections must be intimately 
familiar, on a real time basis, with the status of approximately 4000 (non-nuclear) and 
1200 (nuclear) key operations on a routine ship submarine overhaul. The networks 
that FASS can reproduce on screen or print out at remote stations allows the 
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aforementioned branches a graphic look at actual progress on any given job or series 
of jobs that lead to a key event or milestone. Prior to the acquisition of FASS this 
organizational structure was adequate for the needs of the schedulers and progressmen 
because they usually had to wait two-three days for their work inputs to be processed 
by the SYMIS (Shipyard Management Information System) and returned in network 
or graphic form for analysis. With a real time, user-interactive system integrated with 
the mainframe the needs of the Production Control Branch are satisfied within minutes. 
What has been proposed is a new section in the Production Control Branch that does 
not become directly involved with manpower estimates or manpower requirements 
(Code 376); that does not prepare, issue, and maintain shipyard schedules (Code 377); 
and is not responsible for determining the status of productive work in terms of 
physical progress (Code 378). A completely new section is needed. 

A proposal has been forwarded for the formation of a Automated Systems 
section (Code 379) in the Production Control Branch. This new section would be 
responsible for the following: 

* Administration of the FASS system. 

* Liaison with shipyard progressmen in improvement of graphics and reports. 

* Liaison with the Office of Information Resources (Code 140, Shipyard ADP). 

* Liaison with all shipyard department's automated systems personnel. 

* Liaison with all users of FASS or Production Control products. 

* Assist the work status, scheduling and progress sections. 

* Conduct all scheduling related development work. 

The primary 1 advantage of having a section specifically assigned to developmental 
work and improving graphics is that new ideas from other sources as well as the 
personnel in Code 379 can be synthesized from the ARTEMIS software. The 
improved graphics can be distributed to the other FASS systems in the other shipyards 
and all of the shipyards benefit. Currently. Naval Shipyard Long Beach is involved in 
this organizational change. There seems to be a question of just what FASS is and to 
whom it really does belong. The main emphasis in the Production Control Section is 
that FASS belongs to the Scheduling Section (Code 377). This does not take into 
account the other facets of FASS such as the cost/schedule variances that FASS can 
graphically portray or the different forms that tie scheduling to manpower, milestones, 
and money. The somewhat narrow strategy is that FASS should belong strictly to the 
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Scheduling Section. A more enlightened view is the formation of the separate section 
to assimilate information from the other shipyards and for one small group of people 
to have the expertise of the system. In all of the shipyards 1-9 people work with 
FASS. The move is to hire more clerical types for the pure administrative burden that 
accrues with such a complex system. At Long Beach there are three people: a 
supervisor, a technical operator, and a general computer specialist. This is not really 
enough to completely keep up the daily processing of information from the mainframe 
on the three or more ships that are nearly always in overhaul. It seems logical to have 
a separate section for FASS expertise and to allow the other sections to carry out their 
primary responsibilities in the most efficient manner possible. Portsmouth Naval 
Shipyard, Long Beach Naval Shipyard and Puget Sound Naval Shipyard have 
implemented the formation of the Code 379 while there is a nearly equal division 
among the other shipyards in shifting to the Code 379 organization or maintaining the 
control of FASS in the Code 375 office. Increased organizational effectiveness is more 
easily attained by specialization of functions. It is logical for Code 379 to act as the 
primary FASS experts and let Code 375 attend to the larger functions of production 
control. 

C. FASS USERS GROUP 

With eight shipyards, as with any eight organizational entities with the same 
systems and goals, there is the tendency to carry 7 out business eight different ways. The 
eight Navy shipyards operate under more stringent guidelines than any private sector 
shipyard. Because the jobs in the shipyard are civil service there are problems in 
reducing the work force when an overhaul is completed. This somewhat constant work 
force becomes extremely expensive and cost inefficient in leaner times. The same 
guidelines apply to the ADP section of the shipyard organization. The drive for 
production efficiency is an overriding consideration in the public sector shipyards. To 
ensure a semblance of commonalty and to keep effectiveness at as high a level as 
possible, the FASS User's Group has been organized comprised of the FASS user's and 
implementers in all eight shipyards and SEAADSA. This user group is designed to 
improve inter-shipyard communications in the FASS area by the sharing of ideas and 
products, by setting priorities for system enhancements, and to expedite the 
development of FASS to current state-of-the-art technology. The avowed purpose of 
this group is to improve shipyard operations, reduce overhaul and maintenance costs. 
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and finally to reduce the durations of regular overhauls. The user's group 
accomplishes this lofty aspiration by the following means: 

* Establish and maintain a minimum level of commonaltv in the areas of 
computer hardware, software, and scheduling terminology. 

* Establish and maintain communication between users and automated 
scheduling systems. 

* Share and exchange ideas and products among shipyards. 

* Promote trust and confidence among the shipyard users. 

* Surface scheduling svstem problems and provide mutuallv supportive 
resolutions. [Ref. TO] 

This FASS User's group was initiated to develop a strategy to assist each 
shipyard in obtaining productive status with the FASS system in the shortest possible 
time. Two of the main ideas of the group were the establishment of a core database 
and the problems concomitant with interfaces. 

The core database was to serve as the point of departure for standard process 
and reports development. An input by the user's group was the use of consistent 
conversions of database elements so that any communication between the individual 
shipyards would not be stymied by different and essentially undecipherable computer 
code. It was established that the contents of the core database be limited to those data 
elements used by the majority of the shipyards with built-in capabilities for database 
expansion when FASS capabilities were more fully realized. 

The interface problem was recognized early as one of the most important 
capabilities to be developed between FASS and the shipyard mainframe. The group 
decided that the interface be accomplished by either magnetic tape or a 
communications link (27S0/37S0 protocol). For example; Fong Beach Naval Shipyard 
uses the communications protocol as the interface link with the mainframe while the 
magnetic tape is a historical record. Fong Beach also has the communications link via 
modem to the other shipyard FASS systems for data exchange. At the present time 
this FASS User's Group meets twice a year to discuss problems relating to all of the 
shipyards. The accomplishments of the first three FASS User's Group conclaves have 
been synopsised below: 

* A common core database has been developed for FASS and implemented by 
all shipyards and SEAADSA. 

* Electronic communication procedures and transfer of software routines 
between shipyards have been developed and implemented. 
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* An electronic mail weeklv news bulletin was implemented and shipyard 
procedures for use of the bulletin were established. 

* Procedures for eliminating redundancy of programming by shipyards and 
SEAADSA have been established. 

* Procedures for sharing and soliciting better business practices have been 
established and utilized: 

* Sharing and exchange of methodologies and products between the shipyards 
has been enhanced By the User's Group. 

The latest meeting held in September 19S6 dealt with the growth potential of the 
Code 375 branch of the shipyard. The consensus is that Code 375 rather than the 
shipyard ADP must define and design production information systems. This is a 
radical move for decentralization in the shipyard data processing organization. At this 
stage of implementation the User's Group is fine tuning the FASS system and 
developing new ways for the ARTEMIS software to produce exactly what they want in 
the way of graphics and reports. The FASS User's Group is concerned with two main 
difficulties that may impede full and accurate implementation: (1) Cost/Schedule 
Control System (which will be discussed in the following section) and (2) the Navy's 
competitive bidding policy toward overhaul of ships and submarines. There is 
tremendous concern among all the FASS users that conflicts of interest may arise in 
the shipyards between getting the bid for a ship overhaul and exchanging information 
that may make one shipyard more efficient than another. As can be recalled, one of 
the cornerstones of the FASS User's Group charter was the sharing and exchanging of 
ideas to make all the shipyards more efficient and to cause shorter overhauls which 
would save taxpayer money. This conflict could possibly break down productive 
communications between the shipyards and cause damage to them all. A strong 
solution that has been proposed by the User's Group is for all the Navy shipyards to 
bid as a corporation rather than as individual entities. This would at one stroke 
remove any secrecy and would keep the ideas and exchanges of data flowing between 
the shipyards. 

The FASS User's Group is the strongest force in implementing FASS at an equal 
pace in the shipyards. The exchange of data is helping each shipyard to be more 
efficient and cost productive. The value of the User's Group is the main reason FASS 
is becoming as powerful a tool as it has become. 
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D. COST/SCHEDULE CONTROL SYSTEM 

The Cost. Schedule Control System (CSCS) is an idea that private industry has 
used for years. The primary reason that Naval shipyards have adopted this system is 
to maintain shipyards in a required state for wartime readiness and still meet technical 
requirements of ship overhauls ahead of established schedules and at a reasonable cost, 
preferably under cost. These lofty ambitions are striven for without sacrificing gains 
made in quality and scheduling. The system is designed for the middle managers of the 
shipyard, the general foreman, and shop foreman. A typical shipyard system hierarchy 
is shown in Figure 5.7. [Ref. 11] The elements of a CSCS system include: 

* Discipline-bias toward improvement. 

* Control of overhead expenses. 

* Work organized into manageable packages. 

* A plan to accomplish each package. 

* A measurement of costs of work performed. 

* A measurement of the physical progress of work. 

* Ability to detect variances from the plan and ability to take corrective action. 

[Ref. 11] ^ 

This system is designed to reduce costs in the Navy' shipyards by adhering to the 
principles stated below and shown in Figure 5.8: 

* System based on integritv. Actual cost data and actual schedule progress data 
will be collected for producing a precise report of actual performance. 

* The highest level of the cost hierarchy will be the project budget. 

* Project work scope will be broken down into relatively small work task 
elements which will be assigned a cost estimate and a performance schedule 
which will be the structural foundation for measuring cost and schedule 
performance. 

* Cost performance will be measured by comparing actual costs for work 
performed to planned costs. 

* Schedule performance will be measured by comparing actual progress to 
planned progress at the appropriate levels. 

* Deviation of actual performance from planned performance will be resolved by 
the responsible line manager. [Ref. 12[ 

The primary reason that CSCS is mentioned in the implementation of FASS is 
that even though the full power of FASS is not yet fully understood by the FASS 
users, this new concept is being added to already burdened staffs. Three of the 
shipyards, Long Beach, Mare Island, and Charleston, have arrived at three 
methodologies for CSCS FASS implementation. Long Beach plans to use the shipyard 
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mainframe for CSCS "number crunching" and down-loading to the ARTEMIS 
software for graphic representation as shown in Figure 5.9. Mare Island plans to 
interface the shipyard mainframe to FASS to down-link data from the SYMIS and use 
ARTEMIS software to analyze, and to produce reports and graphics for CSCS. 
Charleston is using the Mare Island approach with the exception of using a different 
software package with ARTEMIS. The User's Group meeting in September held a 
separate conclave dealing specifically with CSCS. The consensus was that Long Beach 
and Charleston provide a summary of their systems development to date and to 
identify the differences between the systems. The group also felt that CSCS 
calculations would be best achieved on the shipyard mainframe and that the standard 
graphics should also be generated on the mainframe due to the volume and 
distribution considerations of the reports. The main complaint of the User's Group 
concerning CSCS is the fact that FASS is being utilized for implementing CSCS in the 
shipyards. This is not what FASS was designed to do. FASS is first and foremost a 
scheduling tool and the addition of a non-scheduling memory sinking concept like 
CSCS is counter productive to a full understanding and utilization of FASS. 
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Figure 5.8 Typical Cost/Schedule Variances Graphics. 
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Figure 5.9 Typical ARTEMIS Software Management Graphics. 
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VI. CURRENT FASS UTILIZATION 



A. PUGET SOUND 

Puget Sound Naval Shipyard has fully implemented FASS and is coping with the 
Cost'Scheduling Control System. FASS at Puget Sound is menu oriented and 
password controlled. There is a nuclear and non-nuclear master schedule built into the 
memory that can be altered with any special overhaul key events, milestones, or jobs 
that may be particular to a certain type of ship or submarine. The system's network 
for the Production Planning Branch is depicted in Figure 6.1. Puget Sound has the 
largest inventory of remote printers and plotters of all the shipyards. Long Beach 
Naval Shipyard is in the process of shifting some of that procured excess to their FASS 
site thereby recognizing an early cost benefit from the Navy's overall FASS system. 
Puget Sound has progressed to the point that the weekly reports endemic to 
Production Control have been placed on permanent disk in the FASS computer room 
and are no longer a part of the shipyard MIS produced reports. Puget Sound is also 
utilizing the "What-If' capability of FASS allowing them to take advantage of the 
ability of the schedulers, foreman, or management to change the event or the duration 
of the milestone or the calender resulting in a new event report incorporating these 
changes and any other concomitant changes in the schedule. 

Puget Sound has incorporated the Cost/Scheduling Control System (CSCS) 
concept into their system and the shipyard MIS. They have recognized the value of 
CSCS to the shipyard and have produced their own training manual. This manual 
shows the schedule hierarchy and explains the CSCS graphics terms. [Ref. 11] As 
stated in chapter five the shipyard mainframe must still do the massive numerical 
manipulations to produce the schedule and cost variances while the FASS graphics 
produces the fmal printouts. Puget Sound has found that the key to success with 
CSCS is a combination of the following: 

* Manageable "packages" of work. 

* A plan to accomplish each package of work. 

* A stable estimating base. 

* Manhour "budget" for each package. 

* Accountability. 

* Accurate labor charging. 
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Figure 6.1 Puget Sound Production Planning Branch Network. 

* Surveillance of labor charges, physical prosress/completion, and specification 
adherence. 

* Real-time reaction to variances. 

* Investigation, resolution. 

* Discipline! 

Puget Sound has organizationally found that Code 379 has control of the FASS 
system in all respects. The reasoning behind this is that the system is in the hands of 
the people that must be familiar with it to best accomplish their jobs. 

B. LONG BEACH 

Long Beach Naval Shipyard has implemented their FASS system as depicted in 
Figure 6.2. This has allowed the mainframe MIS to contain the massive memory and 
allows FASS to remain relatively unencumbered to produce their scheduling reports. 
Long Beach has also developed their own set of CSCS graphics in conjunction with the 
MIS. Additionally, Long Beach produces the automated workload and resource report 
(WARR) that is turned in monthly to NAVSEA. Long Beach has also produced an 
automated overtime tracking report that allows for an audit trail when required. Long 
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Beach has also developed an automatic update of any overhaul schedule based on the 
real time progress as extracted from PCC-268 data. 




Figure 6.2 Long Beach Production Planning Branch Network.. 

Long Beach has developed FASS to its fullest potential by pushing the system as 
far as it will go then modifying it to go further. They have developed resource 
scheduling techniques that allow maximum utilization of the workforce and already 
reduced the overhaul time required on one ship by believing in the output of FASS. 
Long Beach has gone to the other shipyards and is in the process of building a master 
library of ship overhaul schedules based on standard work breakdown structures which 
results in the avoidance of redundant work by their own schedulers. This aspect shows 
great promise of significantly reducing overhead in future overhauls. The immediate 
advantage of having such a library is the time reduction that occurs in responding to 
contract awards in the competition with other public and private shipyards. 

Long Beach is experiencing a slow down of the system while doing large 
networks. It is taking as much as 24 hours to analyze and report on some large 
networks. The apparent source of this slow down is the float allocation procedure is 
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proving to be very time consuming. What this points out is the fact that the 
minicomputer which is the heart of FASS may still be too small in memory capacity to 
handle very large projects. Long Beach feels that although FASS is a scheduling tool 
that has unlimited potential in theory’ it is quite limited in real life by its memory 
capacity. Due to these limitations most of the work has been in producing reports for 
schedulers and shop foreman. The automated overtime and CSCS functions have been 
regulated to third and fourth priorities. 

Other than nagging mini, mainframe interfacing problems the only major casualty 
to their system has been an unreliable CALCOMP 1077 plotter which is now repaired. 
The information gleaned from the repair of this plotter in relation to optimum vacuum 
settings and the squaring of the reference points is of great interest to the other 
shipyards that are experiencing the same problems with their own 1077's. 

Long Beach has implemented CSCS on the FASS system using the guidance 
provided by NAVSEA. [Ref. 12] Additionally. Long Beach has completed CSCS 
reports by performing keyop audit checks on time cards. 

Organizationally Long Beach subscribes to the Code 379 approach as reflected in 
Chapter V. This approach allows the three people who are intimately familiar with 
FASS to look at ways of improving the scheduling aspects and the report formats to 
the schedulers who use them. This removes the burden of R&D from the Code 378 
schedulers and allows Code 379 to constantly improve FASS operations and outputs. 

C. MARE ISLAND 

Mare Island, along with Portsmouth Naval Shipyard were the first shipyards that 
received the FASS system. The software they started with was ARTEMIS 5000. 
ARTEMIS 6000 is now in place at all eight shipyards. This has necessitated some 
small change-overs in procedure for Mare Island. They have a nuclear and non- 
nuclear scheduling master residing on their FASS mini. Mare Island also uses basically 
the same networking model as Puget Sound shown in Figure 6.3. There have been 
small problems in interfacing with the mainframe but with the help of the FASS User's 
Group they have been solved satisfactorily. Mare Island, organizationally, has FASS 
in the Code 377 section of Production Control. In all other respects Mare Island most 
closely resembles Puget Sound in its current FASS utilizations. 
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Figure 6.3 Mare Island Production Planning Branch Network. 

D. PEARL HARBOR 

Pearl Harbor has fully implemented FASS into its Production Control branch. 
Additionally, Pearl has implemented an excellent CSCS package into their system. 
Their CSCS system has been tried on a ship and two submarines. Both the nuclear 
and non-nuclear schedules have been exercised. Pearl Harbor also uses basically the 
same network model as Long Beach Figure 6.4. The shipyard has divided the 
responsibility between Code 377 and Code 379. Code 377 schedules the work and 
Code 379 is packaging the work to support the individual tests. For example, work 
required to support test number 1 will be packaged and scheduled separately from that 
work which would support test number 2. The end product of such a sequence of work 
packages is the test of the entire package as a key event or milestone. An innovation 
that Pearl has developed in Code 143 is a program that extracts data from the SYMIS 
onto a PC. This is done once a week and is reviewed by the individual keyop mangers. 
This data is then run through FASS for local reports only and overall efficiency is 
increasing. This innovation is in its infancy but is already showing great promise. 
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Figure 6.4 Pearl Harbor Production Planning Branch Network,. 

Pearl Harbor shares the same misgivings as the other shipyards regarding CSCS. 
Pearl Harbor has issued a fairly extensive instruction detailing the system in effect. 
Included in this instruction are formats for three reports that could be valuable for 
other shipyards. The reports are synopsised below: 

* PSL-05A = MILESTONE-KEY EVENT SCHEDULING INTERFACE 

1. Combines nuclear and non-nuclear work into one report grouping kevops 

to the milestone-key event interface showing most recent status 
information. 

2. Program highlights kevops that may be deficient. 

3. Program performs automated rescheduling of keyop when the master 
milestone is revised. 

* PSL-05B = CURRENT MKE AND PRODUCTION CONTROL 
SUMMARY 

1. Summarizes potential problem kevops and shows any increases or 
decreases from previous reports. These reports are issued once a week and 
are a tremendous asset for the keyop managers in finding early problems 

Pearl Harbor has developed its own backup procedure to reduce the possibility of 

lost work. A auto backup will occur whenever a user logs off his ID, thus users do not 

have to remember to backup their work every day. The only drawback to this 
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procedure is that it now takes from 20 seconds to three minutes to complete log off. 
This lost time though not important now, will be when the system is more fully loaded. 

E. PHILADELPHIA 

Philadelphia Naval Shipyard is the shipyard that uses the minicomputer (PASS) 
as an interface between existing shipyard computers. The line diagram is shown in 
Figure 6.5. In fact, FASS is a front end user of PASS to the mainframe. CSCS has 
not been implemented at Philadelphia at the present time. There are over 200 
individual jobs required in making it fully operational. Code 226.1 and Code 226.2 
personnel have the new system 90 percent implemented. Long Beach's PC 268 
program has greatly aided Philadelphia in coming as far as it has in implementation of 
CSCS. In other respects, Philadelphia is no different from the other naval shipyards. 
Files are down-loaded from the Honeywell mainframe to FASS for graphic outputs. 
Code 226.2 is moving toward developing automatic updates based on costs. 
Philadelphia has a large SLEP (Service Life Extension Program) in effect and it 
produces specialized reports for those overhauls that are different from the regular 
overhaul reports that FASS has produced. Philadelphia, Long Beach, and Mare Island 
have the float allocation program installed in their FASS system where the other 
shipyards do not. Philadelphia feels that the float algorithm is not strong enough to 
support overhauls. It sometimes takes as long as two weeks to get results from their 
resource loading programs. Another problem has been the inclusion of the SLEP 
program into FASS. It seems that FASS is too small storage-wise to support it. SLEP 
takes up to 55 percent of all FASS memory and leaves only enough room to carry one 
FF size ship in the remainder of its memory. This necessitates a greater than normal 
use of the shipyard mainframe for the scheduling aspects of the other ships in overhaul. 
Philadelphia has a good working FASS system and the PASS minicomputer has proven 
to remove some of the memory and time-lag problems that affect the other shipyards. 

F. CHARLESTON 

Charleston relies heavily on the mainframe. The line diagram is shown in Figure 
6.6. Graphics are done on the shipyard MIS while all reports are generated by the 
MIS and down-loaded to FASS for presentation. Charleston seems to have some 
capacity/ storage problems that the other shipyards have not reported. They also need 
a second 1077 plotter to accomplish the graphics that are required. CSCS has proven 
to be impractical for FASS at Charleston and they have not placed as high a priority 



49 




Figure 6.5 Philadelphia Production Planning Branch Network. 

as some other shipyards have. Organization-wise Charleston utilizes the normal 
shipyard structure where Code 375 is in charge of FASS. Charleston seems to be 
progressing well with their utilization of FASS in the way it was designed: For 
scheduling. With the exception of the storage problems cited above, Charleston does 
not seem to have any major problems with FASS. 

G. PORTSMOUTH 

Portsmouth Naval Shipyard, along with Mare Island, was the first to acquire and 
implement FASS. The network line diagram is shown in Figure 6.7. With the older 
ARTEMIS 5000 software they have had cross-over problems in using the ARTEMIS 
6000 but these appear to have been overcome. As with the majority of naval shipyards 
Portsmouth has a nuclear and non-nuclear master schedule residing in FASS. 
Graphics are done on FASS as well as the reports that are peculiar to production 
control. Their FASS routines are not menu driven. They also have a paucity of 
storage even though they have a library disk such as the one Long Beach produced. 
Portsmouth espouses wholeheartedly the CSCS concept and conducts classes on the 
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Figure 6.6 Charleston Production Planning Branch Network. 

waterfront for added emphasis. Another accomplishment in their FASS displays is that 
after a plot has been completed the information excess is deleted thus conserving disk 
space. Also when the plot is updated the information is stored in the SYMIS rather 
than FASS. The reports that Portsmouth uses are the same as the other shipyards. 
Portsmouth does not have the float allocation application. They are organized with a 
Code 379 to take advantage of that section of production control's expertise in 
developing new and more useful reports to the keyop managers and other top 
management in the shipyard. Code 379 tracks all of FASS's data sets, global variables, 
and fields. They have not experienced any problems in interfacing via modem with the 
other shipyard FASS systems and only minimal communications difficulty interfacing 
with the shipyard mainframe. Portsmouth is the shipyard that has had FASS for the 
longest period and its experience is in demand at the User's Group conferences. 

H. NORFOLK 

Norfolk Naval Shipyard is the largest of the naval shipyards. The line diagram is 
shown in Figure 6.8. It has become imperative that scheduling and cost controls be 
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Figure 6.7 Portsmouth Production Planning Branch Network. 

taken in hand as quickly as possible. Norfolk has fully implemented FASS and CSCS 
with good results. The FASS is menu driven with command files for producing 
graphics and reports. It also issues bar charts and PERT networks to the waterfront 
and has a strong teaching cadre for CSCS. All ships currently in overhaul at Norfolk 
are on ARTEMIS. Norfolk probably makes the most use of its overhaul library disk 
based on the pure volume of ships in overhaul. Norfolk has an excellent 
communication system between the shipyard and the waterfront and has a large 
number of remote sites for a more real time look at all jobs being accomplished by the 
shipyard. Because of its size Norfolk is experiencing some problems in their networks 
and with the communication protocols with the mainframe. They use the 2780 
protocol exclusively at this point. Norfolk is currently unable to run multiple plotters 
at 9600 baud where the other shipyards have not indicated any problem in that area. 
The organization at Norfolk is the standard organization cited in Chapter V, with 
FASS under Code 377. One political problem that is surfacing is between FASS and 
the ADP personnel that run the mainframe. The people that run the mainframe feel 
that FASS should be able to run itself and discourage use of the mainframe for the 
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heavy memory work. FASS also wants to access the PC file but are not allowed by the 
shipyard ADP personnel. Norfolk is trying to resolve these problems expeditiously 
because FASS cannot run as a stand alone system and deliver the reports that the 
keyop managers must have to make their decisions. These reports are issued once a 
week and are a tremendous asset for the keyop managers in finding problems early. 




Figure 6.8 Norfolk Production Planning Branch Network. 
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VII. CONCLUSIONS / RECOMMENDATIONS 



A. CONCLUSIONS 

1. FASS USEFULNESS 

After completion of the interviews and documentation reviews associated with 
system specifications, requirement analysis, official correspondence, personnel 
requirements, background and plans concerned with the acquisition, implementation 
and utilization of FASS, it is evident that: 

* Personnel involved at all levels are dedicated to obtaining a uniformlv hiah 
quality product useable by all shipyards. 

* Personnel requirements are interpreted very differently at all shipvards and 
even at different levels in each shipyard, ranging from impressive to minimal. 

* Definition of what FASS is, and what it should be used for, varies greatly in 
its extent yet does not vary in what it is. 

* FASS is meeting all requirements and specifications as determined prior to 
purchase; however use of the system has shown that all requirements and 
specifications were not defined enough to meet todays requirements. 

* The selected ARTEMIS system is having a positive impact on the the 
shipyard scheduling process and overall effectiveness. 

When used as designed, or as modified to meet the individual shipyards 
requirements FASS will continue to have a growing impact on all shipyards both 
operationally and economically. With continued and improved communications 
between all shipyards, XAVSEA, and SEAADSA, FASS will continue to be modified 
to support the present and ever changing demands placed on it by the users. 

2. NETWORKING 

A key concern of each shipyard continues to be just how to, and to what 
extent. FASS should be networked with the existing systems. FASS was designed as a 
stand alone system but has proven to be more fully utilized if networked with the 
existing shipyard systems. The limited memory capacity of FASS requires it to use the 
data storage capacity which resides in the existing shipyard computer systems to obtain 
maximum efficiency. This requirement must be met by the required data stored in the 
SYMIS being passed to FASS via a network scheme of some type thus allowing FASS 
to use its limited memory capacity for processing vice the data storage. This 
requirement could be met by manual entry of data as it is required; however, this 
would be a step back in time negating one of the major qualities of FASS that being 
the timeliness of FASS provided information and results. 
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3. ACCEPTANCE 

Shipyard management has met the test and although each has answered it in 
slightly different ways all have passed by proving that FASS is now and will be the 
only way to do scheduling in the shipyards. Some of the upper management have used 
the "JUST DO IT" approach while others have been more diplomatic in their approach 
but the end result has been the same as all levels of all eight shipyards are rapidly 
joining or are already on board that FASS is the only way to go now and in the future. 
With each modification to FASS. management will again have to face the acceptance 
problems but they will be much smaller in magnitude and should be much easier to 
meet. 

4. GROWTH POTENTIAL 

As FASS is accepted to greater levels in the shipyards it will face an ever 
increasing problem with growth. That is; as the managers, supervisors, and users more 
fully comprehend and understand the systems applications, they will want to have the 
system do more and more things for them in their own way. Many different reports 
and graphs can be generated by both the main and desktop versions making it very' 
attractive for each person to want to have the data entered or presented in a special 
way for his specific need. This type of usage not only duplicates information storage 
requirements but also increases processing time taking it away from other services the 
system was initially designed for. Growth of this type is not necessarily wrong but is a 
major control problem as more personnel become familiar with the system. 

5. CONTROL 

As reflected in the previous section on Growth, a frequent problem associated 
with computer systems is the growth of its usage after the initial learning phase is 
completed. This problem requires close and continued attention by upper level 
shipyard management and is a primary reason for the formation of Code 379 as a 
central control point for the overseeing and regulation of the usage of FASS. 
Continued success of the system depends on employing it for additional applications; 
however, these applications must be uniform and applicable to more than just one user 
of the system. A prime example of this is the introduction of CSCS onto the system 
only to find that while it has produced good results it has overloaded FASS and 
decreased its usefulness for its intended purpose: Scheduling. This does not suggest 
that new and useful modifications cannot be made to FASS but that the introduction 
of such modifications must be carefully controlled and monitored. This control is 
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being done by local PASS managers and overall by SEAADSA and the PASS users 
group. 

6. PERSONNEL MANNING AND UTILIZATION 

The status of personnel manning at all eight shipyards in the area of FASS is 
up in the air without a standard policy for having or not having a Code 379. Each 
individual shipyard has gone its own way in establishing just what its manning will be 
and what it will be called. In order for FASS to be utilized as it was designed to do a 
standard policy must be set and adhered to as much as possible considering the 
differences in the networking methods applied by each shipyard. 

The authorized and actual manning levels are summarized below in Table 1. 

TABLE 1 

FASS MANNING LEVELS 



SHIPYARD 


AUTHORIZED 


ACTUAL 


CODE 










Puget Sound 


9 


5 


379 


Long Beach 


5 


3 


379 


Mare Island 


-> 




379 


Pearl Harbor 


T 


T 


■ 375.1 


Philadelphia 


7 


2 


226 


Charleston 


6 


4 


377 


Portsmouth 


7 


7 


379 


Norfolk 


1 


1 


377.6 



The request produced by Portsmouth Naval Shipyard is a start in the right 
direction. Without a common code with a common experience level required for that 
code it will continue to be a problem for the shipyards to communicate and work with 
each other. Despite the best intentions of all involved a GS-9 with only a scheduling 
background working in code 377.9 cannot accomplish as much as a GS-12 with both 
scheduling and computer background working in code 379 when dealing with other 
code 379s from other shipyards or when dealing with the contractors involved. 

7. COST/SCHEDULE CONTROL SYSTEM 

While CSCS is a very important and valuable requirement for operation of the 
shipyard its association with FASS is not desirable. After close review of the Long 
Beach, Mare Island, and Charleston initiatives several items concerning the 
development of a standard CSCS automation are evident; 

* Use of estimates versus allowances or the combination of the two in 
performing CSCS calculations. 
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* Where data originates and how it becomes part of the Production Control 
master file in each shipyard. 

* Calculation of the Budgeted Cost of Work Scheduled (BCWSi. Three curves 
are being used or planned (Original BCWS. Current BCWS. and Revised 



* Which schedule dates are being used (earlv start. earlv finish or allocated 
start; allocated finish) to trace "work and what is the' potential effect on 
schedule variance? 

* Schedule variance at the line item level when estimates are made at the kev 
operation level. 

* Should CSCS calculations take place on the mainframe, minicomputer 
(FASS). or combination of the two? 

* Where should CSCS graphics be produced, how should they be distributed, 
and how many copies of each? 

The Cost/Schedule Control System is still in the developmental stages of its 
use in Naval shipyards and as such many of the answers are not yet available. A 
continuing process of solicitation of requirements and the follow up feedback is 
necessary. 

8 . IN-HOUSE REVIEW 

FASS has now' been in use at Portsmouth and Mare Island for an extended 
period of time allowing these shipyards to conduct an in-house review of the systems 
effectiveness and use-ability. The other shipyards may at any time conduct their own 
in house review but must take into account the time period the system has been in 
place and the amount of exposure to the total shipyard workforce it has had. This 
review is not meant to be a one time event and must be an ongoing requirement placed 
on the FASS system managers by the shipyard commanders if FASS is to continue to 
be utilized and improve as it has demonstrated it has the capability of doing. The 
areas covered by the review may vary from shipyard to shipyard and time to time but 
the major areas that should be covered are: 

* Assessment of overall performance of the system. Is it an asset or has it 
become a liability? 

* Accessibility and response time. 

* Information flow, amount, and form. 

* Program effectiveness. 

* Training effectiveness. 

* Are there confusing or unused areas of the system? 

* Is FASS assisting or burdening the supervisors? 

* Is the system being utilized by all levels and areas of the shipyard? 
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These on going reviews will take a considerable amount of time but are 
necessary to preclude the possibility of misuse or nonuse of the system. [Ref. 13] 

9. NAVSEA REVIEW 

In that each shipyard has undertaken an individual approach to PASS and its 
utilization the effectiveness of each approach must be evaluated by an outside source 
(in this case NAVSEA). Just because one shipyard is having great success with one 
form of implementation and utilization of FASS is definitlv no guarantee that the other 
seven shipyards would succeed using that form. The major factor affecting the success 
or failure of the system at individual shipyards may not be in the method of 
implementation and utilization but instead might be management support, training or 
acceptance. [Ref. 14] These factors cannot be reviewed by internal organizations and 
must be approached from a knowledgeable but disinterested point of view. 

B. RECOMMENDATIONS 
1. SHIPYARDS 

The following list of recommendations apply to all of the shipyards or 
interactions between them: 

* Establish a common basis for utilizing FASS for its intended purpose: 
Scheduling. 

* Establish a common dataset definition for mandatory fields to be extracted 
from the SYMIS master files for FASS use. 

* Report results and findings of resource leveling efforts on FASS for use by all 
shipyards. 

* Promulgate command file and documentation for loading shop, work center 
information as network resource records. 

* Review float allocation for use and optimization by all shipyards. 

* Promulgate the source and extent of CALCOMP expertise for the benefit of 
all shipyards. 

* Review TLR updating process for replacement by FASS applications, in the 
two shipyards that are still using PS(TLR). 

* Promulgate process for updating network based on actual finish dates and 
physical" progress. 

* Share the Puget Sound Naval Shipvard Event Management and Lead 
Shop/Key Shop instruction. 

* Provide a network for checking validation files (dummies, loop) prior to input 
to SYMIS or other systems. 

* Develop lists of scheduling problems, scheduling methodology used, types of 
schedules, and tvpes of reports used for exchange with each other and 
discussion at following FAS$> users group meetings. 

* Develop lists of hardware, software or svstem utilization problems for 
discussion resolution at following FASS users' group meetings. 
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Exchange samples of FASS products as produced at individual shipyards. 
Utilize SEAADSA as a central design agency for new standard applications. 

SEAADSA 

SEAADSA should be responsible for acquiring providing the following items: 

Development of new standard applications as required by the shipyards. 

l imine test results on Metier float allocation process using large sized network 
data to evaluate the extent of the slow-down problem. 

Establish communication with the ARTEMIS users association to exchange 
routines of possible interest to Navy or other PASS users. 

NAYS E A 

It is recommended that NAVSEA do the following: 

Take action expeditiouslv on the Portsmouth Naval Shipyard request for 
establishment of Code 379. Consider the extensive merits of establishing a 
Code 379 at all shipyards as part of the standard shipyard organization. 

Promulgate, in writing, the NAVSEA policy for FASS information and data 
sharing In light of theVequirement for competitive bidding between shipyards. 

Establish a policy for integration of FASS within each shipyard information 
processing system. 

Establish policv for CSCS calculations to be achieved on the SYMIS. 
Graphic products should also be generated on the mainframe due to volume 
and distribution considerations. 

Direct the formation of an advisory group to the CSCS Implementation 
Review Team consisting of shipyard personnel who are being tasked to 
implement the automation of the CSCS tool in the shipyards. 
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VIII. FURTHER RESEARCH OPTIONS 



By January 1987 the entire shipyard complex should be capable of using 
ARTEMIS version 6.1 as their main scheduling tool as well as for Cost Schedule 
Control. The different implementation approaches along with the varied results in 
networking and utilization of PASS will provide an excellent opportunity for further 
research on (1) How the shipyards view FASS, (2) How the shipyards utilize FASS, 
and (3) Lessons learned concerning the purchase and use of commercial software 
altered for use in the Naval shipyards. A study of these lessons will identify actions 
required for success which in turn will benefit all aspects of computer use in the 
government military complex. 
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